Saying no
to customer feature requests
Image credit: Simpsons Wiki
Homer’s car
There’s a ton of literature about how to say no to feature requests and why. Intercom have written many great articles on the topic and I love this short, punchy explanation from the team at Basecamp:
The secret to building half a product instead of a half-ass product is saying no.
We’re also fans of the story of the car that Homer Simpson built. When one voice in a process over-rules all others (such as the collective voice of the customer) you can end up with a product like Homer’s car…
Homer's creation was such a monstrously strange car, cost so much to develop, and had such a high price tag (Approximately $82,000), that Herb's car company went out of business shortly after - Simpson’s Wiki
Let that be a warning to us all…!
So the art of saying no
is well-developed, it’s highly relevant to all SaaS product teams because it’s an intrinsic and everyday part of the job that many people struggle with. The mechanism of saying no
is also part of a much bigger philosophy of how we should interact with customers to give all users (and our business) the best possible outcome.
The rise of customer success
Despite the clear challenges of handling feedback from customers alongside internal stakeholders & business objectives, most SaaS businesses agree that working with customers is vital in facilitating growth:
…in my experience, building a product and process that helps your customers achieve their Desired Outcome is the path to success. You simply cannot do this without a strong customer feedback loop, so it’s pretty much invaluable if used correctly - Lincoln Murphy, Gainsight
You have to fearlessly say no
to feature requests. Done correctly within a solid culture of building value for you users means it actually helps to build strong relationships.
Listening to customers and helping them be successful is a key role of a SaaS product team particularly…
…with the shift to a SaaS model...the connection between your customer’s success and YOUR success is much more direct and felt much more quickly – Ken Lownie.
After many years building software products and as a proud veteran of saying no
for the greater good, I still found myself surprised last week when a SaaS product manager told me they choose to completely ignore customers. It came from a product we were considering using but their response as to how they handle customer feedback put me off so I found myself carefully questioning why.
Prioritizing our roadmap isn’t a democratic process — especially from our customers
That’s a quote from a SaaS Product Manager this week, the emphasis is mine. Can you imagine anyone actually putting that on their website for customers to read? I decided not to buy that product.
Don’t get me wrong, it’s hard getting the balance right…your SaaS product is not a democracy…but in our experience customers have always been a fantastic source of validation for roadmap items and product improvements.
You can never be your customer, and their success has such an impact on your business that choosing to ignore product feedback & feature requests in favour of a we know best
attitude is old school to say the least.
Here’s some of the things we’ve learned along the way….
How do you get the balance right?
Having a dedicated channel to gather and understand feedback & feature requests from customers had a massive impact in our last SaaS business. Support calls dropped dramatically leaving the channel free for real issues and customer success gained hours in productive customer enablement time.
However it’s vital to balance the voice of the customer against internal teams and business objectives:
In a SaaS company your teams have their own priorities too. Sales, Customer Service, Product Team, Leadership etc…all have insights to bring. Without understanding the needs of your internal teams, you aren’t giving your business the best chance of developing features in a way which fits with the overall strategy of the business. Priorities for your teams are constantly shifting so you need to capture this data and get everyone working towards the same goals.
Remember…don’t just build a product your customers love, build the product your business needs.
Have a process
With the rise of support teams and customer success, some SaaS product managers have less direct exposure to customer requests. Depending on how these teams operate, they may act as a much needed shield for the product manager but the reality for many is that these teams add to the backlog of feedback & feature requests coming from the customer base.
Make sure teams understand the company line on how customer feedback & feature requests are handled - have a process. Getting this right is a massive selling point for new prospects too so gather and understand customer feedback in a way that works for you, other teams
The most frequently requested features aren’t the ones you build
If everyone is screaming out for a feature, you’d better be listening, and working out what the underlying problem is.
New feature DOES NOT = problem solved
For example, in our last SaaS business the most frequent request would be to integrate with the popular ecommerce system Magento. It has millions of installs, dozens of versions in the wild (with no easy upgrade path resulting in many users on very old version), it’s hundreds of different host OS, firewall configs, PHP modules….Oh My GOD why would you ever build that?
Leave it to the big guys that can devote 8 developers to supporting something like that, and focus on supporting the thing that fits right. Be narrow, be focussed.
And never just count feature votes…understand the pain points, the prioritisation and which customer groups are affected. What if the most popular feature is requested by free triallers who are a bad fit? Always understand the who and the why.
Communication & transparency are your friend
Having communication & transparency with your customer base makes saying no
easy. Instead of agonizing over what to say to which customers and when, having a transparent process and keeping customers updated on feedback & feature request progress does wonders for customer relations and does that difficult no
task for you.
We wrote about this previously in our post - You should build this because your other customers need it:
Get customer feature requests into your request management system and request feedback from the rest of your customer base and internal teams. Killer features (things solving a real problem for your other users) & real pain points will be jumped on, voted for and prioritised while un-required requests will be ignored.
Once you’ve allowed enough time for feedback, you can respond with a balanced argument -
Thanks for the suggestion but there isn’t the demand for this right now so it’s not going into the product backlog.
Sharing a high-level release log and product roadmap with your users can also be beneficial.
Adding transparency and additional voices to the conversation will help the customer see that their request isn’t going to be built but also that there’s a ton of other great stuff you are building.
This approach also allows you to manage customer expectations a lot more realistically than the generic almost-auto-reply we’ve put it on the list
and it fights the pile everything into Trello and hope for the best
mentality.
It always surprises me how a little transparency and validation (or not) from other users changes the perception of your customers from:
You’re not listening or building what I want,
To:
Wow, you’re really responsive, look at all the ace stuff you’re building!
This happens. Honestly it does. So in summary, do say no
but do it in the right way; within a culture of respecting and valuing your customers.
How much influence do you allow your customers have? Do you think it’s healthy for their collective voice to be heard?
